原帖 ｜ 🌶 ｜ 2026-01-26 14:50 ｜ 👍1 ｜ 阅读约1
问题模型三 （替换ddr和emmc后内核崩溃问题）
项目背景：鉴于最近国外ddr和emmc价格飞涨，出于降本问题，公司选择拥抱国产，替换国产ddr和emmc，替换之后，同样的系统固件，出现内核崩溃等问题
问题分析定位：
硬串口监控到Starting kernel出现后就一直停留在这了
显然，这是一个黑盒问题，我们最直接的debug方式，串口无法直接抓取，对于问题发生我们一无所知，自然无法定位收敛问题，那么，此时我们的思路应该出现转变：没有日志要创造日志。原因：我们是有参照组的，替换前是可以正常启动，替换后就不行，那么大概率是硬件和设备树之间的适配问题，但我们是按照厂商提供的文档进行适配的，那么就需要我们拿到问题日志跟厂商反馈问题从而拿到解决方案。
实验设计：
那么现在最重要的是拿到/创造出这个日志，怎么做呢？通过翻阅文档和资料，我梳理出两个比较合适的方法：
1.开启 Kernel Pstore (Persistent Storage)
Pstore 可以将内核崩溃前的最后信息（printk log）保存到特殊的存储区域（如 RAM 的某一段、Flash 或抹除不掉的寄存器中），即使系统重启，日志依然存在。
2. 硬件辅助：JTAG / SWD 调试器
操作： 在系统卡死时，不要复位，直接通过 JTAG 连接 CPU。
能力： 挂起 CPU，查看当前的 PC (Program Counter) 指针停在哪里。
查看调用栈，确认是否陷入了死循环或某个特定的驱动函数。
读取内存中的 log_buf 缓冲区，直接手动提取内核日志。
出于时间成本和操作成本考虑，先尝试方案一：因为方案二不仅需要JTAG，还需要连接CPU，需要协调硬件搭建测试环境，耗时较长，所以该方案更适合难以复现必须出现时当场抓取定位问题的场景，而由于该问题是基本必现的场景，不需要考虑实时性，所以选择方案一
实践步骤：
实现方式： 在内核配置中开启 CONFIG_PSTORE 和 CONFIG_PSTORE_RAM (RAMOOPS)。
原理： 系统崩溃重启后，你可以去 /sys/fs/pstore/ 目录下找 dmesg-ramoops-0 文件。
优势： 专门解决“死机后日志带不出来”的问题。
注意：该方案需要软重启确保RAM不掉电（掉电信息会丢失），我们直接按下reset按键即可
相关笔记
- 📁 返回本主题 MOC
- Linux BSP问题闭环流程
- 从MCU转Linux BSP开发
- 嵌入式Linux调试iic
- PCIe调试与问题排查
- 老师，学习Android Camera架构时
- 很多人不知道 Android 和 Linux（如 Ubuntu） 的关系